I have a comment about this that may just be due to my naivete with Azure IAM.

I wanted to test this by logging in as my own user (joe.wilder@lacework.net) that has fairly broad privileges, and then creating a "low privilege" test role and service principal that only has "Microsoft.Authorization/roleAssignments/*" and "Microsoft.Authorization/roleDefinitions/*" permissions at root management group scope. My plan was to then use this "low privilege" service principal to test the permissions bootstrapping code here.

When I tried that, I was unable to since my joe.wilder@lacework.net user does not have permission to create roles that operate at root management scope.

So it seems to me that there is a chicken-and-egg problem where the "low privilege" user needs to have some level of access to the root management group to bootstrap the deployment. And if you have permission to create roles at management group scope then ... this user probably isn't very "low privilege" after all?

This code is still valuable even if that is true -- access to the root management group doesn't guarantee the user will have all of the other permissions we require -- but I'm mostly just wondering if I understand the requirements and limitations correctly. Does the above sound correct to you?

Yes, your understanding is correct @wilderj — having those permissions scoped to the root management group means that the is required to create and assign roles in any subscription within the root mgmt group (the tenant). This is required because (in addition to the scanning subscription) we also create and assign roles in the various monitored subscriptions.

Indeed, the principal used to execute this TF module does require such permissions and can be considered rather privileged — having said that, I agree that this module is still valuable in the sense that it makes life easier for whichever admin on the customer side is responsible for creating this service principal for the deploying team to use.